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Executive  Summary 

This  report  focuses  on  a standard  means  of  spedfying  the  interface  between  applications  and  one 
of  the  communications  subservices  available  in  modem  computer  systems.  This  standard  interface 
is  an  appropriate  element  of  the  enabling  technology  required  for  the  proposed  National  Information 
Infrastructure  (Nil). 

The  Nil  is  a vision  for  using  presently  emerging  information  technology  to  improve  products  and 
services,  create  new  ones,  compete  more  effectively,  and  empower  people  to  be  more  creative  and 
efficient.  The  key  prerequisite  for  the  Nil  is  the  availability  of  computing  environments  that  consist 
of  distributed,  heterogeneous,  networked  applications,  databases,  and  hardware.  The  concept  of  a 
Federal  computing  environment  that  is  built  on  an  infrastructure  defined  by  open,  consensus-based 
standards  is  well  on  its  way  to  becoming  a de  facto  means  of  organizing  these  systems.  Such  an 
infrastructure  is  called  an  Open  System  Environment  (OSE). 

An  OSE  supports  interoperability,  portability,  and  scalability  of  computerized  applications  across 
networks  of  heterogeneous,  multi-vendor  platforms  by  forming  an  extensible  framework  that  allows 
services,  interfaces,  protocols,  and  supporting  data  formats  to  be  defined  in  terms  of  nonproprietary 
specifications.  Typically,  these  specifications  have  evolved  through  open  (public),  consensus-based 
forums. 

A selected  suite  of  specifications  that  defines  the  interfaces,  services,  protocols,  and  data  formats 
for  a particular  class  or  domain  of  applications  is  called  a profile.  NIST  has  defined  a specific  federal 
application  profile  composed  of  publicly  available  specifications  from  industry,  federal,  national, 
international,  and  other  sources.  This  profile,  named  the  Application  Portability  Profile  (APP), 
provides  the  functionality  necessary  to  accommodate  a broad  range  of  federal  information 
technology  requirements. 

The  APP  is  not  a standard.  It  is  a framework,  detailed  in  NIST  Special  Publication  500-210,  designed 
to  help  users  determine  which  specifications  to  use.  The  APP,  however,  does  not  Imply  that  there 
is  any  integration  of  other  commonality  among  the  specifications  it  contains.  Furthermore,  the  APP 
is  not  intended  for  use  In  system  integration. 

A specific  organization  will  not  necessarily  require  ail  of  the  recommended  specifications  in  the  APP. 
As  the  U.S.  Government's  OSE  profile,  this  guidance  is  provided  to  assist  federal  agencies  in  making 
Informed  choices  regarding  the  selection  and  use  of  OSE  specifications,  and  in  the  development  of 
more  selective  application  profiles  based  on  the  APP.  It  is  directed  toward  managers  and  project 
leaders  who  have  the  responsibilities  of  acquiring,  developing,  and  maintaining  information  systems 
supported  by  heterogeneous  application  platform  environments. 

One  of  the  specifications  evaluated  In  the  APP  is  the  Application  Software  Interface  (ASI)  for 
Integrated  Services  Digital  Network  (ISDN)  services.  The  ASI  is  one  of  the  Network  Services 
evaluated  in  the  APP.  It  Is  an  implementation  agreement  produced  by  the  North  American  ISDN 
Users'  Forum,  based  on  national  and  international  standards  for  ISDN.  This  report  provides  specific 
supplementary  information  to  the  APP  so  that  users  may  make  informed  judgements  on  the 
applicability  of  the  ASI  specification  to  their  environment. 

The  ASI  fits  within  the  architecture  of  the  OSE  Reference  Model  (OSE/RM)  and  provides  services 
that  are  within  the  scope  of  the  APP  Network  Services  Functional  Area.  The  APP  defines  network 
services  for  data  communication,  transparent  file  access,  personal/micro  computer  support,  and 
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remote  procedure  call.  These  network  services  provide  the  capabilities  and  mechanisms  to  support 
distributed  applications  requiring  data  access  and  applications  interoperability  in  heterogeneous, 
networked  environments.  Data  communication  includes  interface  and  protocol  specifications  for 
reliable,  transparent,  end-to-end  data  transmission  across  communications  networks.  The  ASI 
architecture  defines  reference  points  that  correspond  to  the  interfaces  defined  in  the  OSE/RM  for 
the  APP  data  communications  network  services. 

The  ASI  specification  focuses  on  the  definition  of  a common  application  Interface  for  accessing  and 
administering  ISDN  services  provided  by  hardware  commonly  referred  to  in  the  vendor  community 
as  Network  Adapters  (NAs).  It  is  intended  to  be  independent  of  the  data  protocol  type  and  it  does 
not  address  either  peer-to-peer  protocol  or  Interoperability  issues. 

While  the  ASI  was  developed  for  an  environment  that  utilizes  ISDN  technology,  the  specification  is 
also  applicable  to  other  environments  that  utilize  other  telecommunications  technologies.  All  these 
technologies,  including  Asynchronous  Transfer  Mode  (ATM)  as  well  as  ISDN,  are  rapidly  becoming 
available  in  telecommunications  networks  throughout  the  United  States.  Since  telecommunications 
services  will  be  a major  element  of  the  Nil,  the  ASI  deserves  consideration  as  an  element  of  the 
enabling  technology  required  for  the  proposed  Nil. 

The  key  Issue  Is  to  determine  how  the  ASI  fits  into  descriptions  and  specifications  of  the  Nil.  The  Nil 
architecture  Is  still  under  development  but  It  is  already  clear  that  the  ASI  can  fit  into  the  specification 
of  Nil  environments  in  three  ways; 

(1)  For  those  environments  in  the  Nil  that  incorporate  the  OSE/RM  and  the  APP,  the  ASI  Is 
automatically  included. 

(2)  For  some  other  Nil  environments,  an  appropriate  profile  can  be  constructed  by  a judicious 
combination  of  present  ASI  specifications  with  other  publicly  available  interface 
specifications. 

(3)  Future  ASI  work  to  include  additional  interfaces  specifications  could  satisfy  needs  for 
additional  environments  within  the  Nil. 
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1.  Introduction 


Federal  agencies  are  under  increasing  pressure  to  use  information  technology  to  improve  efficiency 
and  delivery  of  services  to  the  public.  Systems  that  were  originally  developed  as  isolated  islands  of 
computing  no  longer  meet  enterprise-wide  needs  for  common  application  architectures, 
communication  networks,  and  databases.  In  addition,  it  Is  no  longer  possible  for  any  single  vendor 
to  supply  all  of  the  required  Information  technology  systems  and  services.  Since  very  large 
homogeneous  environments  are  no  longer  practical  in  many  cases,  users  need  open  systems  that 
provide  Interoperability  of  products  and  portability  of  people,  data,  and  applications  throughout 
heterogenous  computing  environments. 

The  need  to  Improve  portability  and  interoperability  has  resulted  in  widespread  interest  In  standards 
such  as  the  Portable  Operating  System  Interface  for  Computing  Environments  (POSIX)  and  Govern- 
ment Open  System  Interconnection  Profile  (GOSIP)\  POSIX  and  GOSIP,  however,  are  not  sufficient 
to  address  the  full  spectrum  of  needs,  even  within  their  stated  scopes  of  concern.  Therefore,  the 
National  Institute  of  Standards  and  Technology  (NIST)  has  published  an  Application  Portability  Profile 
(APP)  to  provide  additional  guidance  to  federal  agencies  in  making  Informed  choice  regarding  the 
selection  and  use  of  OSE  spedficatlons  and  in  the  development  of  OSE  profiles. 

The  APP  provides  two  types  of  guidance  based  on  the  functional  service  areas  present  in  an  OSE. 
First,  specifications  are  provided  for  each  functional  service  area  described  In  the  APP.  Second,  and 
equally  as  important,  evaluation  criteria  to  assist  In  making  qualitative  assessments  of  the 
recommended  specifications  are  defined  and  applied.  The  NIST  assessments  are,  in  fact,  the  results 
obtained  by  applying  these  evaluation  criteria  to  the  recommended  specifications. 

Users  of  the  APP  are  expected  to  use  the  evaluation  criteria  to  make  their  own  assessments  of  the 
recommended  specifications.  Further,  users  may  choose  to  assign  weighted  values  to  elements  of 
the  criteria  based  on  their  own  judgement  of  the  relative  importance  to  be  given  each  element. 
Users  may  also  require  vendors  to  use  the  evaluation  criteria  to  assess  specifications  that  the 
vendors  choose  to  propose  as  an  alternative  to  the  specifications  recommended  in  this  document. 
In  any  case,  the  user  of  the  APP  needs  to  have  some  technical  knowledge  of  the  applicable 
elements  in  a given  profile. 


1.1  Scope 

This  report  provides  the  specific  information  required  to  evaluate  the  Application  Software  Interface 
(ASI)  as  one  component  of  an  Open  System  Environment  (OSE)  which  might  include  POSIX,  GOSIP 
and  other  specifications  to  provide  the  functionality  necessary  to  address  a broad  range  of  federal 
Information  technology  requirements. 

The  ASI  is  one  of  the  Network  Services  evaluated  In  the  APP.  It  Is  an  implementation  agreement 
produced  by  the  North  American  ISDN  Users'  Forum,  based  on  national  and  International  standards 
for  ISDN.  This  report  provides  specific  supplementary  Information  to  the  APP  so  that  users  may 
make  informed  judgements  on  the  applicability  of  the  ASI  specification  to  their  environment.  The  next 
two  sections  provide  introductory  material  on  the  Application  Portability  Profile  and  Integrated 


^GOSIP  is  transitioning  to  Profiles  for  Open  System  Internetworking  Technologies  (POSIT), 
which  will  provide  guidance  but  will  not  mandate  procurement  or  any  other  form  of  compliance. 
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Services  Digital  Networks.  Section  2 briefly  describes  the  definition  of  an  open  system  environment, 
the  OSE  Reference  Model,  and  specific  components  of  the  Application  Portability  Profile  while 
Section  3 examines  the  history  and  present  status  of  ISDN  technology.  The  intent  is  to  provide 
context  to  the  reader  on  the  relationships  between  ISDN  and  the  APP. 

Section  4 provides  an  overview  of  the  ASI  and  Section  5 applies  the  APP  evaluation  criteria  to  ASl. 
The  API  and  EEI  interfaces  are.  In  general,  the  subject  of  on-going  refinement.  Section  6 looks  at 
possible  near  term  developments  that  are  of  interest. 

Finally,  this  report  includes  an  extensive  bibliography  to  assist  interested  parties  in  obtaining  the 
specifications,  requirements  and  reports  that  contain  detailed  information  on  the  various  components 
of  the  APP  and  the  ASI. 
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2.  Open  System  Environment 

An  Open  Systems  Environment  (OSE)  is  a computing  infrastmcture  that  supports  portable,  scalable, 
and  Interoperable  applications  through  standard  services,  Interfaces,  data  formats,  and  protocols. 
The  standards  may  consist  of  international,  national.  Industry,  or  other  open  (public)  specifications 
that  are  available  to  any  user  or  vendor  for  use  in  building  systems  and  products  that  meet  OSE 
cnteria.  In  an  OSE,  users  will  be  able  to  buy  and  use  applications  that 

• Execute  on  any  vendor’s  platform  and  use  any  vendor’s  operating  system; 

• Communicate  and  interoperate  over  any  vendor’s  networks; 

• Access  any  vendor’s  database;  and 

• Interact  with  users  through  a common  human/computer  interface. 

Applications  In  an  OSE  are  scalable  among  a variety  of  platform  and  network  configurations,  from 
stand-alone  microcomputers,  to  large  distributed  systems  that  may  include  microcomputers, 
workstations,  minicomputers,  mainframes,  and  supercomputers,  or  any  configuration  in  between. 
Thus,  an  application  will  run  in  an  OSE  irrespective  of  the  amount  of  resources  available  in  that 
environment.  Of  course,  the  user  will  find  that  satisfactory  performance  will  require  the  availability 
of  sufficient  resources  in  the  OSE.  For  example,  the  available  data  processing  power  and 
communications  bandwidth  are  significant  factors  in  determining  the  speed  of  response  for  many 
applications. 

Applications  interoperate  by  using  standard  communication  protocols,  data  interchange  formats,  and 
distributed  system  interfaces  to  transmit,  receive,  understand,  and  use  information.  The  process  of 
moving  Information  from  one  platform,  through  a local  area  network,  wide  area  network,  or 
combination  of  networks  to  other  platforms  should  be  transparent  to  the  application  and  the  user. 
Locations  of  other  platforms,  users,  databases,  and  programs  should  also  be  transparent  to  the 
application.  In  short,  an  OSE  supports  applications  through  the  use  of  well-defined  components:  that 
can  be  used  as  system  building-blocks. 

2.1  OSE  Reference  Model 

The  Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  POSIX  Working  Group  PI 003.0 
describes  an  OSE  Reference  Model  (OSE/RM)  that  provides  a framework  and  a terminology  for 
describing  open  system  concepts. 

As  shown  in  Figure  1 below,  the  OSE/RM  Is  composed  of  three  entities  with  two  interfaces. 

• The  Application  Software  Entity  consists  of  the  programs  that  perform  specific  tasks  for 
the  user.  The  application  software  also  Includes  any  associated  data,  documentation,  and 
training. 

• The  Application  Platform  Entity  is  the  Integrated  system  of  hardware  and  software 
components  that  provide  the  services  used  by  application  software. 
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• The  Platform  External  Environment  consists  of  those  system  elements  that  are  external 
to  the  application  software  and  the  application  platform  (e.g.,  services  provided  by  other 
platforms  or  peripheral  devices). 

• The  primary  function  of  the  Application  Program  Interface  (API)  is  to  support  portability  of 
applications.  The  OSE/RM  defines  API  services  for  (1)  the  internal  system,  (2) 
communication,  (3)  information  interchange,  and  (4)  the  human/computer  interface. 

• The  External  Environment  Interface  (EEI)  supports  Information  transfer  between  both  (1) 
the  application  platform  and  the  external  environment  and  (2)  applications  executing  on  the 
same  platform.  Mainly  concerned  with  Interoperability,  the  EEI  provides  services  for  (1) 
communication  with  other  application  platforms,  (2)  information  transfer  to  and  from  external 
data  stores,  and  (3)  information  exchanges  between  human  users  and  the  computer. 


Figure  1.  Open  System  Environment  Reference  Model  (OSE/RM) 


In  its  simplest  form,  the  OSE/RM  illustrates  a straightforward  user-supplier  relationship:  the 
application  software  entity  is  the  user  of  services  and  the  application  platform  and  external 
environment  entities  are  the  suppliers.  The  interfaces  between  the  three  entities  define  the  services 
that  are  provided,  as  seen  at  two  distinct  places  within  the  reference  model. 
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2.2  Application  Portability  Profile 


An  OSE  profile  is  composed  of  a selected  list  of  open  (public),  consensus-based  standards  and 
specifications  that  define  services  in  the  OSE/RM.  The  selected  list  of  standards  and  other 
specifications  define  a set  of  complementary  services  that  are  made  available  to  applications  in  a 
specific  domain.  Examples  of  domains  might  include  a workstation  environment,  an  embedded 
process  control  environment,  a distributed  environment,  a transaction  processing  environment,  or 
an  office  automation  environment,  to  name  a few.  Each  of  these  environments  has  a different  cross- 
section  of  service  requirements  that  can  be  specified  independently  from  the  others.  Each  service, 
however,  is  defined  in  a standard  form  across  ail  environments. 

The  Application  Portability  Profile  Is  an  OSE  profile  designed  for  use  by  the  U.S.  Government.  It 
covers  a broad  range  of  application  software  domains  of  interest  to  many  federal  agencies,  but  it 
does  not  include  every  domain  within  the  U.S.  Government's  application  inventory.  Detailed 
descriptions  of  the  APP  services  are  available  in  NIST  Special  Publication  500-210  Application 
Portability  Profile  (APP).  The  individual  standards  and  specifications  in  the  APP  define  data  formats, 
interfaces,  protocols,  or  a mix  of  these  elements. 

2.2.1  APP  Service  Areas 

The  APP  defines  seven  service  areas  that  are  closely  related  to  the  OSE/RM.  As  shown  In  Figure 
2 below,  the  seven  areas  are:  (1)  operating  system  services,  (2)  network  services,  (3)  data 
management  services,  (4)  humaiVcomputer  interface  services,  (5)  graphics  services,  (6)  data 
interchange  services,  and  (7)  software  engineering  services.  (Several  of  the  services  areas  appear 
at  both  the  API  and  the  EEI  and  software  engineering  services  are  applicable  in  all  areas  of  the  API 
and  EEI.) 

Each  of  the  APP  service  areas  addresses  specific  components  around  which  Interface,  data  format, 
or  protocol  specifications  have  been  or  will  be  defined.  In  addition,  security  and  management 
services  are  common  to  ail  of  the  service  areas  and  pervade  these  areas  In  one  or  more  forms. 
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Figure  2.  APP  Service  Areas  and  the  OSE/RM 


2.2.2  Evaluation  Criteria 

The  APP  defines  evaluation  criteria  to  assist  in  making  qualitative  assessments  of  the  APP 
specifications.  Users  of  the  APP  are  expected  to  use  these  evaluation  criteria  to  make  their  own 
assessments  of  the  recommended  specifications.  Further,  users  may  choose  to  assign  weighted 
values  to  elements  of  the  criteria  based  on  their  own  judgement  of  the  relative  importance  to  be 
given  each  element.  Users  may  also  require  vendors  to  use  the  evaluation  criteria  to  assess 
specifications  that  the  vendors  choose  to  propose  as  an  alternative  to  the  specifications 
recommended  in  this  document.  In  any  case,  the  user  of  the  APP  needs  to  have  some  technical 
knowledge  of  the  applicable  elements  in  a given  profile. 
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Each  service  area  in  the  APR  is  preceded  by  a summary  status  report  of  all  specifications  reviewed. 
The  summary  status  report  in  the  APP  relates  the  results  of  major  evaluation  criteria  (e.g.,  level  of 
consensus,  completeness,  etc.)  to  a graphic  representation.  With  one  view, -all  of  the  specifications 
in  a particular  service  area  can  be  compared  to  determine  relative  coverage  of  the  area.  Users  may 
use  this  Information  to  determine  where  they  should  concentrate  their  efforts  in  tailoring  and 
augmenting  application  and  organizational  profiles. 

The  APP  entry  for  ISDN  ASI  is  shown  in  Figure  3.  The  seven  spedfic  evaluations  of  the  AS  I are  also 
described  In  paragraphs  of  the  APP. 


SPECIFICATION 

LOC 

PAV 

CMP 

MAT 

STB 

DFU 

PRL 

ISDN  ASI 

• 

O 

• 

O 

O 

O 

Legend:  •-high  evaluation  O-average  evaluation  blank-low  evaluation 

LOG  - Level  of  consensus  STB  - Stability 

PAV  - Product  availability  DFU  - De  facto  usage 

CMP  - Completeness  PRL  - Problems/limitations 

MAT  - Maturity 

Figure  3.  ASI  Summary  Status  Report  in  the  APP. 

2.2.3  Strategic  Evaluations 

The  APP  provides  guidance  to  the  users  on  the  strategic  value  of  each  spedfication.  The  valuations 

are  made  according  to  the  following  guidelines: 

• Strategic  now — In  selecting  these  specifications,  users  would  be  reasonably  safe  In  making 
substantial  investment  and  long-term  plans  covering  mission-critical  systems  and  the 
infrastructure  needed  to  support  them.  Changes  are  expected  to  be  upwardly  compatible. 

• Strategic  in  the  future — Specifications  that  are  subject  to  change  but  appear  to  be  headed 
for  standardization  fall  into  this  category.  Existing  standards  that  may  be  subject  to  changes 
that  are  not  entirely  upwardly  compatible  also  fall  into  this  category.  There  are  some  long- 
term risks  involved,  but  the  actions  of  the  consensus-building  process  will  tend  to  minimize 
them.  Users  should  select  these  specifications  where  strategic  specifications  are  unavailable 
and  an  investment  must  be  made,  but  should  plan  for  possible  evolution  in  the  future. 

• Nonstrategic — ^These  specifications  are  stop-gap  measures  recommended  with  the  warning 
that  any  user  investment  will  be  at  significant  risk.  They  are  not  appropriate  for  long-term 
planning.  Users  should,  for  these  reasons,  minimize  their  risk  by  minimizing  investment. 

The  APP  evaluates  the  ASI  as  strategic  in  the  future. 
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3.  Integrated  Services  Digital  Networks 

NIST  has  identified  the  deployment  of  Integrated  Services  Digital  Network  (ISDN)  technology  as  the 
next  step  in  the  evolution  of  the  telecommunications  industry.  This  emerging  technology  offers 
immense  potential  benefits  to  government,  industry  and  personal  users  through  its  capability  to 
exchange  voice,  data  and  image  information  concurrently  over  telephone  lines.  With  ISDN,  computer 
and  communication  technologies  converge  to  speed  and  simplify  the  flow  of  Information  between 
sender  and  receiver  In  ways  that  were  not  previously  possible. 

ISDN  is  a set  of  integrated  telecommunications  services,  available  over  public  and  private 
telecommunications  networks.  The  sen/ices  are  defined  over  a digital  point-to-point  circuit-switched 
medium.  Thus,  unlike  a packet-switched  medium  like  X.25,  ISDN  establishes  a dedicated  circuit 
between  two  machines  (e.g.,  computer  or  bridges).  It  can  transmit  either  packetized  or  asynchronous 
digital  information  without  a modem,  so  it  can  be  used  for  anything  a modem  can,  including 
connecting  two  LANs.  For  instance,  work  at  home  applications  that  respond  too  slowly  even  over 
high  speed  modems  can  use  ISDN  services  that  Interface  directly  into  a departmental  LAN  and  use 
the  same  software  and  provide  access  to  ail  the  data  as  if  the  worker  was  in  the  office.  With  ISDN, 
still  and  motion  video  pictures  can  be  sent  between  two  or  more  parties  without  the  need  for  special 
conference  rooms  full  of  expensive  equipment  and  colleagues  can  jointly  edit  a report,  graphics 
and/or  a spreadsheet  while  talking  on  the  telephone,  even  though  they  are  hundreds  of  miles  apart. 

A key  feature  of  ISDN  is  the  use  of  a separate  channel  for  control  information:  call  setup,  network 
management,  Automatic  Number  Identification  (ANI,  also  known  as  Caller  ID),  and  so  forth.  This 
feature  gives  ISDN's  one  of  its  most  notable  advantages  over  high-speed  modems,  which  otherwise 
approach  it  in  terms  of  raw  speed.  The  separate  control  channel  noticeably  reduces  the  time  to  make 
a connection.  It  takes  only  a fraction  of  a second  to  establish  a local  ISDN  connection  and  only  2 
to  5 seconds  for  a long  distance  connection.  This  compares  favorably  with  up  to  90  seconds  for  a 
modem  connection  over  any  distance. 

Since  ISDN  is  a switched  digital  service,  its  ability  to  provide  bandwidth  on  an  as-needed  basis  to 
support  digital  connections  makes  it  an  essential  building  block  of  the  nation's  information 
infrastructure.  The  ability  of  ISDN  to  set  up  a connection  so  quickly  makes  it  ideal  for  on-demand 
LAN-to-LAN  connectivity.  Rather  than  paying  for  dedicated  digital  lines  that  the  LAN's  sporadic 
activity  leaves  unused  much  of  the  time,  an  ISDN  bridge  or  network  interface  card  can  connect  the 
remote  computer  to  the  LAN  on  demand.  The  ISDN  device  monitors  LAN  traffic,  and  when  It  detects 
a packet  addressed  to  a remote  LAN,  the  connection  is  made,  the  data  transferred,  and  the 
connection  closed  without  any  knowledge  or  action  by  the  user. 

For  convenience  in  providing  the  appropriate  voice  and  data  services,  ISDN  divides  its  total 
information  transmission  capacity  Into  channels  that  either  provide  bandwidth  to  send  user  data  or 
to  open,  control  and  close  the  connection.  ISDN  further  defines  two  service  interfaces,  known  as  the 
Basic  Rate  Interface  (BRI)  and  the  Primary  Rate  Interface  (PRI). 

The  BRI  consists  of  two  64  kbps  data  channels,  called  B channels,  and  one  16  Kbps  out-of-band 
control  channel,  called  the  D channel.  The  combination  Is  called  2B+D.  The  two  B channels  can  be 
combined  Into  one  128  Kbps  data  channel,  or  kept  divided  to  simultaneously  make  a digital  phone 
call  on  one  B channel  while  using  the  other  for  data  communications  or  video  conferencing. 

B channels  can  alternate  between  voice  and  circuit-data.  The  BRI  D channel  bandwidth  is  also 
available  for  user  packet-data  messages  when  it  is  not  being  used  for  call  control. 
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Primary  Rate  ISDN  (PRI)  combines  23  B channels  and  one  64-Kbps  D channel,  yielding  the  same 
capacity  as  a T1  line,  only  with  far  more  flexibility.  In  PRI,  B channels  can  be  assigned  on  a call-by- 
call  basis  and  the  D channel  is  only  used  for  call  control;  packet-data  is  not  supported.  ''Multirate" 
calls  can  also  be  placed  over  PRI.  Multirate  ISDN  calling  provides  wideband  channels  at  any 
multiple  of  64  kbps  B channels  ("N  by  64"). 

3.1  ISDN  Standards 

The  ISDN  is  defined  by  a number  of  standards  for  the  exchange  of  many  types  of  information  (voice. 
Image,  and  data)  independent  of  any  manufacturer,  service  provider,  or  implementation  technology. 
ISDN  standards  fall  into  two  categories  based  on  the  speed  of  information  transfer.  The  Initial  set 
of  Narrowband  ISDN  standards,  for  transmission  rates  up  to  1.5  Mbps,  have  been  available  since 
the  late  1980s.  Broadband  ISDN  standards,  for  higher  transmission  rates  up  to  several  Gbps,  are 
now  emerging. 

In  North  America,  ISDN  standards  are  developed  by  T1,  a committee  accredited  by  the  American 
National  Standards  Institute  (ANSI).  Within  Committee  T1  there  are  various  Technical  Sub- 
committees (TSCs)  which  have  developed  and  continue  to  develop  the  standards  that  are  the  basis 
for  Interoperable  ISDN  products. 

International  ISDN  standards  are  the  province  of  ITU-T,  formerly  CCITT.  The  TSCs  of  Committee 
T1  provide,  through  the  State  Department,  the  technical  work  for  the  United  States'  positions  on 
ISDN  standards  in  the  International  arena.  Whenever  possible,  the  ITU-T  recommendations  are 
accepted  as  applicable  for  ISDN  in  North  America.  For  special  situations  that  are  only  relevant  to 
North  America,  the  ITU-T  recommendations  are  modified  as  necessary  and  issued  as  standards  by 
Committee  T1.  Of  course,  the  goal  of  international  ISDN  is  promoted  by  using  the  ITU-T 
recommendations  to  the  greatest  extent  possible. 

3.2  NIUF 

In  an  effort  to  overcome  the  barriers  to  the  widespread  acceptance  and  use  of  ISDN  technology,  the 
Advanced  Systems  Division  within  NIST  collaborated  with  industry  in  1988  to  establish  the  North 
American  ISDN  Users'  Forum  (NIUF).  The  NIUF  brings  together  the  communities  involved  in 
progressing  ISDN,  including  users,  service  providers,  network  equipment  manufacturers,  customer 
premises  equipment  manufacturers,  and  applications  software  developers. 

The  NIUF  is  composed  of  two  workshops:  the  ISDN  Users'  Workshop  (lUW)  and  the  ISDN 
Implementors'  Workshop  (IIW).  The  lUW  produces  Application  Requirements  which  describe 
potential  applications  of  ISDN  and  the  features  which  may  be  needed.  The  IIW  develops  Application 
Profiles,  Implementation  Agreements,  and  Conformance  Criteria  which  provide  the  detailed  technical 
decisions  necessary  to  implement  an  Application  Requirement  in  an  Interoperable  manner. 

Each  workshop  is  further  subdivided  into  groups  to  accomplish  specific  tasks.  For  example,  the 
Application  Analysis  Group  provides  initial  analysis  of  potential  user  ISDN  applications  and  provides 
support  in  the  development  of  user  requirements.  The  Signaling  Experts  Working  Group  (SWG) 
writes  Implementation  Agreements  based  on  relevant  ANSI  standards  for  ISDN  call  control  and 
signaling  functions.  The  ISDN  Conformance  Testing  Group  (ICOT)  addresses  the  testing 
methodology  required  to  ensure  proper  implementation  of  applications  and  implementation 
agreements.  The  Application  Software  Interface  Expert  Group  has  produced  a specification  of  the 
interface  between  applications  that  use  ISDN  services  and  the  device  that  provides  the  access  to 
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those  services.  It  is  worth  noting  that  the  NIUF  intends  to  be  neither  a standards-making  body  nor 
a testing  and  certification  organization. 

The  deployment  of  BRI  and  PRI  in  North  America  is  finally  occurring,  even  though  it  still  is  not 
proceeding  fast  enough  to  satisfy  its  proponents.  A wide  variety  of  ISDN-compatible  products  are 
now  available.  These  devices  range  from  ISDN  digital  telephones  to  PC  add-in  cards  that  expand 
local  area  network  connections  across  town  or  across  the  country.  Many  local  telephone  companies 
are  making  ISDN  widely  available.  Pricing  for  ISDN  services  has  been  established  in  most  locations. 
And  now,  these  local  telephone  companies  are  improving  customer  service  as  they  make  more  of 
their  central  offices  "ISDN  ready”.  The  ability  to  connect  these  local  switches  with  a long  distance 
carrier  is  also  being  accommodated. 
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4.  Application  Software  Interface 


4.1  Introduction  To  The  ASi 

The  Application  Software  Interface  (ASI)  is  a specification  defined  by  the  Application  Software 
Interface  Expert  Group  of  the  North  American  ISDN  Users’  Forum  (NIUF).  It  is  a way  for  an 
application  and  an  entity  that  provides  ISDN  services  to  communicate  within  an  operating 
environment  (the  operating  environment  includes  the  operating  system,  hardware  platform,  bus, 
etc.).  The  ASI  is  defined  as  the  interface  between  applications  that  use  ISDN  services  and  the 
network  adaptor  (NA)  that  provides  the  access  to  those  services.  The  translation  of  the  ASI 
message  set,  to  and  from  the  instructions  needed  to  operate  any  hardware  interfaces,  is 
accomplished  by  software  (e.g.,  a device  driver  supplied  by  the  NA  vendor). 

A NA  is  typically  Implemented  as  a card  that  plugs  into  the  input/output  bus  of  a computer  system. 
Today,  manufacturers  are  producing  an  ever  increasing  number  of  NAs  that  offer  a common  basic 
subset  of  ISDN  services  plus  those  additional  features  that  differentiate  their  product  from  the 
competition.  There  is,  however,  little  commonality  In  the  software  Interface  that  these  NAs  currently 
present  to  an  application.  Each  NA  vendor  provides  the  ISDN  service  access  through  a proprietary 
Interface  that,  done  In  Isolation,  differs  from  the  Interface  provided  by  other  vendors.  This 
complicates  the  design  of  the  application.  The  developer  Is  faced  with  the  task  of  (1)  binding  with 
an  initial  NA  and,  once  the  application  is  fielded,  (2)  working  to  enhance  the  application  product  to 
interface  with  other  NAs  as  well.  Exemplifying  this  process  are  products  in  the  market  today  that 
advertise  that  they  “currently  work  v^th"  a specific  set  of  network  adaptors  and  " will  support”  other 
specific  network  adaptors. 

The  ASI  specification  significantly  reduces  complexity  through  a common  interface  for  accessing  the 
ISDN  services  provided  through  the  NA  . The  availability  of  NAs  built  to  ASI  specifications  enables 
the  design  of  applications  that  are  Independent  of  the  particular  NA  with  which  they  are  used.  Within 
a given  operating  environment,  applications  can  run  on  any  ASI-compliant  NA. 

Since  the  ASI  specifies  a common  set  of  services  which  are  applied  across  a broad  range  of 
environments,  it  is  much  easier  to  implement  applications  that  are  portable  across  operating 
environments.  Portability  favors  the  application  developer  by  making  the  application  available  for  a 
wider  audience  and,  at  the  same  time,  widespread  application  availability  Increases  the  demand  for 
ISDN  services,  hastening  deployment  of  ISDN  lines,  and  thus  ultimately  benefitting  the  hardware  (or 
ISDN-capable  computer  platform)  vendors  as  well. 

The  ASI  places  emphasis  on  a common  application  interface  as  opposed  to  a common  hardware 
device  interface  for  two  main  reasons: 

• Maximum  benefit  to  the  user  Is  derived  from  a large  selection  of  commercially  available  ISDN 
applications  which  can  operate  over  a correspondingly  large  selection  of  NAs.  The  number 
of  applications  will  be  most  Influenced  by  the  existence  of  a common  application  interface 
that  allows  the  application  provider  to  easily  migrate  applications  to  different  NAs  and  to 
different  environments. 

• It  is  much  more  difficult  to  specify  a standard  hardware  device  Interface.  Vendors  provide 
different  NA  hardware  interfaces  to  appeal  to  different  markets.  For  example,  some  NAs  will 
be  built  for  performance  while  others  will  be  built  for  low  cost. 
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Objective 


The  primary  goal  of  the  ASI  is  to  provide  a portable,  extensive,  and  layered  software  Interface  to 
ISDN  hardware,  call  control,  and  services.  The  ASI  is  a consistent  set  of  implementation  agreements 
on  a common  set  of  ISDN  services,  enabling  an  application  written  against  the  ASI  specification  to 
communicate  with  any  ASI-compliant  ISDN  NA. 

The  ASI  promotes  the  development  of  application  software  that  can  utilize  ISDN  services  provided 
by  a broad  range  of  ISDN  vendor  products  on  a variety  of  application  platforms.  Applications  written 
against  the  ASI  specification  should  run  on  a computer  platform  employing  ISDN  interface  hardware 
from  different  vendors  without  recompilation  or  linking.  The  same  application  should  be  portable  to 
a different  computer  platform  (with  the  same  operating  system)  by  recompiling,  with  no  changes 
required  to  the  source  code.  For  a different  operating  system,  there  may  be  some  code  changes  to 
accommodate  differences  in  the  access  method.  The  ASI  is  designed  to  be  as  independent  as 
possible  of: 

• Hardware  Platform, 

• Operating  System, 

• Data  Protocol  Type, 

• Programming  Language,  and 

• Compiler. 

Scope 

The  ASI  is  defined  In  terms  of  services  and  facilities  consistent  with  OSI  layer  interface  standards 
and  it  is  designed  to  be  (1)  portable  across  the  broadest  range  of  system  architectures,  (2) 
extensible,  and  (3)  abstracted  beyond  ISDN  to  facilitate  interworking. 

The  ASI  specifies  interactions  at  the  abstract  boundary  between  an  application  and  a NA  within  an 
operating  environment  (the  operating  environment  includes  the  operating  system,  hardware  platform, 
bus,  etc.).  The  ASI  does  not  address  interoperability  between  the  applications  that  utilize  the 
services  offered  by  the  NAs. 

Approach 

The  Implementation  of  the  common  ASI  services  is  the  job  of  the  NA  designer.  NA  vendors  are 
accustomed  to  providing  either  device  drivers  or  libraries  which  provide  the  interface  to  their  specific 
hardware  implementation. 

Access  methods,  however,  are  operating  system  dependent.  The  application  developer  should  have 
to  do  as  little  as  possible  to  port  an  application  written  for  one  operating  system  to  a different 
operating  system  (e.g.,  to  re-compile  or  re-link  is  perceived  as  minimal  effort).  Also,  within  one 
operating  system,  the  application  developer  should  be  able  to  design  applications  independently  of 
the  NA  (i.e.,  the  application  should  work  the  same  and  without  modification  on  the  variety  of  NAs 
available),  assuming  the  NA  provides  equivalent  services. 

Several  assumptions  have  gone  into  the  development  of  the  Version  1 ASI  specification.  Two  main 
assumptions  are: 


14 


• ISDN  primary  rate  and  basic  rate  access  are  assumed  to  be  the  network  interface  to  the  NA. 
This  does  not  preclude  application  of  this  interface  to  NAs  which  interface  to  other  ISDN 
access  methods. 

• No  default  values  for  parameters  are  assumed  by  the  interface.  All  parameter  values 
necessary  for  a message  must  be  supplied  in  the  applicable  data  structures. 

4.2  Technical  Overview 

The  AS  I is  positioned  at  the  Service  Access  Point  (SAP)  between  layers  3 and  4 in  the  OSI 
Reference  Model.  Conceptually,  the  ASI  Is  an  asynchronous  message  stream  between  the  ISDN 
network  services  provider  (layers  1-3)  and  the  user  (layers  4+)  of  those  services. 

Since  the  ASI  is  a local  Interface  between  layer  4 and  layer  3,  It  is  neither  a layer  within  the  OSI 
Reference  Model  nor  an  end-to-end  protocol.  Such  features  as  Interoperability  or  end-to-end  Integrity 
must  be  provided  by  protocols  above  the  ASI,  using  ISDN  network  services  accessed  through  the 
ASI.  If  a non-empty  transport  layer  protocol  is  positioned  above  the  ASI,  then  that  transport  protocol, 
and  not  the  higher  layer  application,  is  the  actual  user  of  the  ISDN  bearer  services  provided  through 
the  ASI.  The  ASI  specifies  a complete  Interface  composed  of 

• A message  set  that  is  independent  of  the  operating  system, 

• A message  encoding  method  that  is  independent  of  the  operating  system,  and 

• An  access  method  that  Is  not  Independent  of  the  operating  system. 

The  partitioning  of  the  ASI  in  terms  of  the  operating  system  dependent  access  methods  allows  the 
rest  of  the  ASI  to  exist  independent  of  the  operating  system.  The  use  of  an  identical  message  set 
and  Identical  encoding  method  for  the  different  operating  systems  greatly  simplifies  application 
portability. 

The  ASI  specification  is  composed  of  four  parts.  The  first  part  provides  an  initial  specification 
Intended  to  allow  Implementors  to  begin  using  the  ASI  for  implementations  of  applications  requiring 
a limited  subset  of  ISDN  services  within  a limited  set  of  operating  systems.  The  other  parts  specify 
the  access  methods  for  specific  operating  systems. 

ASI  Part  1:  Overview  and  Protocols  (Version  1.0)  was  Initially  approved  by  the  NIUF  In  October  1991 
and  an  update  was  approved  in  October  1992.  This  document  Includes  (1)  an  introduction  to  the 
ASI  concepts,  (2)  a description  of  the  ASI  architecture,  and  (3)  a description  of  the  ASI  access 
functionality. 

Parts  2,  3 and  4 of  the  ASI  provide  the  ASI  access  method  for  DOS,  Windows,  and  Unix 
respectively.  ASI  Part  2:  MS-DOS  Access  Method  (Version  1)  was  approved  by  the  NIUF  in  June 
1992.  ASI  Part  3:  Enhanced  DOS/Protected  Mode  Shell  Access  Method  (Version  1)  was  also 
approved  In  June  1992  and  an  update  was  approved  in  October  1992.  ASI  Part  4:  Unix  Access 
Method  (Version  1)  was  also  approved  by  the  NIUF  in  October  1992. 

Concepts 
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Telecommunication  standards  identify  three  distinct  services  for  the  transmission  of  management, 
control,  and  user  information.  These  services  are  represented  by  three  planes  in  the  genera! 
teleservices  architecture: 

• The  management  plane  service  supports  the  exchange  of  ail  Information  associated  with 
operation,  administration,  and  maintenance  (configuration  data,  provisioning  data,  etc.)  of 
the  interface  and  modules  that  support  the  Interface. 

• The  control  plane  service  provides  the  capability  to  establish,  control  and  release  network 
connections,  manage  the  use  of  shared  resources,  modify  service  characteristics,  and 
provide  supplementary  services. 

• The  user  plane  service  passes  user  data  between  the  two  sides  of  a connection.  Use  of  the 
user  plane  is  dictated  by  a connection’s  bearer  service.  These  services  are  based  on  the 
ISDN  protocol  reference  model  defined  in  ITU-T  Recommendation  1.320. 

AS  I focuses  on  the  control  plane  service.  The  ASI  message  set  and  operating  system  specific 
access  methods  provide  an  asynchronous  interface  to  ISDN  call  control.  The  application  makes 
requests  through  the  ASI,  and  the  ISDN  call  control  beneath  the  ASI  transmits  confirmation 
messages  and  event  Indication  messages  back  through  the  ASI  as  appropriate.  After  Issuing  the 
request,  the  application  can  continue  execution  while  it  awaits  the  response  to  the  request. 

Any  blocking  or  synchronous  interface  to  the  ISDN  call  control  can  be  provided  as  a library  of 
function  calls  on  the  application  side  of  the  ASI.  To  implement  a blocking  call  request,  the  application 
sends  the  connection  request  message,  and  awaits  the  connection  confirmation  response. 

Teleservices  Architecture 

The  ASI,  based  on  experience  with  the  OSI  Reference  Model  and  numerous  examples  in  distributed 
computing,  models  the  environment  as  composed  of  protocol  layers  bounded  by  Intefaces.  In  this 
case,  the  teleservices  architecture  Is  split  into  several  abstract  layers  that  define  functionality.  The 
layers,  however,  do  not  imply  correspondence  to  those  of  the  OSI  Reference  Model. 

The  key  element  In  the  ASI  architecture  Is  a generic  teleservices  server.  Such  a server  offers 
teleservices  to  applications  on  the  local  machine  and/or  on  the  local  area  network  without  requiring 
the  applications  to  implement  the  details  of  ISDN,  Plain  Old  Telephone  Service  (POTS),  (The  Public 
Switched  Telephone  Network  (PSTN),  or  other  possible  teleservices  media. 

While  the  ASI  architecture  establishes  a client-server  relationship,  it  neither  supports  nor  precludes 
multi-tasking.  A multi-tasking  operating  system  makes  It  possible  for  multiple  processes  to  access 
ISDN  services  through  a server  architecture  that  minimizes  the  ISDN-specific  knowledge  required 
of  the  application.  This  server,  or  the  single  application  in  a single  threaded  operating  system, 
communicates  with  ISDN  call  control  over  a lower  level  interface  which  more  closely  mirrors  the 
ISDN  protocol.  In  this  architecture,  it  is  the  responsibility  of  a server  interface  definition  to  provide 
the  capability  for  multiple  client  applications  to  access  the  services  provided  by  a single  interface 
adaptor. 

The  ASI  defines  reference  points  and  message  protocols  across  the  reference  points.  The  reference 
points  above  the  generic  server  provide  generic  telephony  Interface  functions,  while  the  lower  level 
reference  points  more  closely  match  ISDN-specific  message  and  event  types.  The  architecture 
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defines  a total  of  five  reference  points  to  accommodate  the  range  of  functionality  that  the  interface 
must  support.  The  architecture  with  its  reference  points  is  shown  in  Figure  4 below. 


Teleservices  Architecture  for  Call  Control 


In  ASI  Version  1,  the  A reference 
point  is  not  an  exposed  interface.  It 
is  defined  to  be  the  Interface 
between  the  “standard”  portions  of 
Q.931  and  the  non-standard 
portions.  Only  the  non-standard 
portions  of  ISDN  need  to  be 
customized  for  each  market. 

The  B reference  point  is  the 
interface  between  a server  or 
dedicated  application  and  the  ISDN 
signaling,  management  and  user 
planes.  Direct  multi-client  access  is 
not  allowed. 

The  C reference  point  presents  a 
generic  teleservices  Interface  to  the 
server  or  dedicated  application. 

The  D reference  point  allows  a 
server  to  provide  a generic 
teleservices  interface  to  multiple 
client  applications.  This  interface 
also  presents  a simplified 
programming  model  to  the 
application  or  toolkit  developer. 

The  E reference  point  is  the 
programming  interface  provided  by 
a high  level  library.  This  interface  is 
the  one  most  desired  by  typical 
applications  developers. 


The  current  release  of  the  ASI 
specification  defines  the  core  subset  of  the  lower  level  reference  point.  Version  1 ASI  is  identified 
as  the  message  stream  at  reference  point  B in  this  architecture.  It  is  to  this  reference  point  which 
vendors  must  supply  ASI  support.  No  vendor-specific  software  need  operate  above  this  reference 
point,  although  a vendor  may  choose  to  provide  higher  level  support  for  added  value  to  an  ISDN 
product. 


In  an  OSE  where  the  application  platform  (see  Figure  2)  provides  generic  teleservices,  the  ASI 
architecture  fits  into  the  network  services  portion  of  the  OSBRM  with  reference  points  A,  B and  C 
describing  elements  of  the  EEI  and  reference  points  D and  E describing  elements  of  the  API. 


ASI  Sessions 
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The  application  and  the  NA  communicate  across  the  ASI  by  reference  to  a local  virtual  path  called 
a session.  A session  carries  all  requests  and  responses  for  a given  instance  of  a service,  e.g.,  a 
voice  call.  Sessions  are  created  dynamically  by  either  the  application  or  the  NA  according  to  the  rules 
defined  by  the  ASI  protocol.  Once  established,  a session  is  referred  to  by  a session  ID  that  consists 
of  a pair  of  values.  One  value  is  determined  by  the  application  program  entity  and  the  other  by  the 
NA  entity.  To  allow  for  dynamic  creation  of  sessions  by  either  side,  each  side  may  create  its  part  of 
the  session  ID  without  consulting  the  other  side.  Either  side  may  refer  to  a session  by  using  the 
other’s  part  of  the  ID.  An  ID  of  ail  zeros  indicates  that  the  other  side’s  ID  is  unknown  or  is  not  used. 
Retiring  and  reuse  of  old  IDs  is  carefully  managed  by  the  protocol. 

The  ASI  uses  Session  Blocks  to  specify  sessions.  These  blocks  are  Implicitly  created  when  a 
connection  is  established.  Session  Blocks  have  pre-defined  attributes  to  use  various  teleservices. 

Messages 

ASI  transfers  information  In  messages  using  an  asynchronous  mode  of  operation  that,  in  non-multi- 
tasking  operating  systems,  prevents  the  processor  from  being  blocked  waiting  for  a response  from 
the  NA.  When  an  application  sends  a message  to  the  NA  by  calling  a function,  control  returns 
immediately  to  the  application  and,  at  some  later  time,  the  NA  sends  a message  to  the  application 
Informing  It  of  an  event  (possibly  related  to  the  earlier  application  message).  For  example,  a connect 
request  returns  immediately  to  the  application.  Some  time  later,  the  application  receives  the 
asynchronous  connect  confirm  message. 

In  order  to  meet  the  portability  and  network  transparency  requirements  of  the  architecture,  all 
messages  are  required  to  be  self  contained.  Furthermore,  messages  shall  not  contain  pointers,  or 
other  references,  to  external  data  structures. 

Message  definition  Is  specified  in  Abstract  Syntax  Notation  Number  One  {ASN.1).  Actual  message 
encoding,  however,  uses  an  ASI  specific  method  that  promotes  ease  of  implementation  and 
improves  performance  while  providing  for  future  expansion  of  the  protocol. 

The  ASI  acknowledges  the  transfer  of  messages  across  the  interface,  indicating  success  or  reason 
for  failure  to  transfer  the  message.  The  messages  are  thus  transferred  across  the  Interface  in  an 
acknowledged  or  synchronous  fashion  even  though  the  mechanism  with  respect  to  the  ISDN  is 
asynchronous. 

Management  plane  services  (e.g.,  protocol  parameters  for  terminal  adaptation)  are  presently 
provided  in  ASI  by  using  a control  part  of  the  user  plane.  The  philosophy  is  to  maximize  the  potential 
performance  of  the  ASI  by  minimizing  the  protocol  overhead.  The  AS!  simply  moves  buffers  of  data. 
If  a protocol  is  implemented  on  the  B channel,  then  this  Is  done  either  entirely  below  the  ASI  or 
entirely  above  the  ASI. 

The  ASI  defines  the  method  of  transferring  data  as: 

(1)  The  application  program  calls  the  data  transfer  function  in  the  ASI,  passing  It  a reference 
(pointer)  to  the  data  and 

(2)  The  ASI  then  copies  the  data  and  returns  to  the  application. 
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The  ASI  specification  does  not  address  peer-to-peer  protocols  across  the  ISDN.  No  messages  for 
sending  data  over  the  B channel  are  defined  in  the  ASI.  However,  the  operating  system  dependent 
parts  of  the  ASI  specification  do  define  a method  to  obtain  the  address  of  a function  in  the  user  plane 
for  the  purpose  of  transferring  data.  In  DOS,  for  example,  the  ASI  defines  two  character  device 
drivers  collectively  called  the  Address  Resolution  Device  Driver  (ARDD).  The  application  and  the  NA 
use  one  device  driver  to  obtain  addresses  for  the  management/control  function  and  the  other  device 
driver  to  obtain  addresses  for  the  user  plane  function. 

Access  Method  Functionality 

The  access  method  provides  mechanisms  to  transfer  management,  control  and  user  Information 
(commands,  events,  data,  etc.)  across  the  ASI.  These  services  are  common  to  all  operating  system 
environments  and  consistent  with  the  ISDN  protocol  reference  model.  However,  since  the 
implementation  of  these  mechanisms  Is  operating  system  dependent,  the  access  method  Is  also 
operating  system  dependent. 

Even  though  the  ASI  includes  access  method  definitions  specific  to  each  operating  system 
environment  (i.e.,  DOS,  UNIX,  OS/2,  etc.),  each  of  these  access  methods  uses  a software  structure 
that  is  consistent  across  all  operating  system  environments.  This  produces  an  access  method  which 
is  optimal  for  its  operating  system  environment  by  applying  a system  dependent  wrapper  around  an 
ASI  software  module  that  is  operating  system  Independent. 

4.3  Summary  of  ASI  Features 

The  current  version  of  the  ASI  is  designed  to  support: 

• A language  Independent  implementation. 

• The  highest  level  of  performance  possible. 

• Minimal  use  of  system  resources  (memory,  soft  Interrupts,  etc.). 

• Simple  system  administration. 

• A binary  compatible  interface  that  requires  no  linkage  or  recompilation. 

• A bidirectional  asynchronous  operation  across  the  interface. 

• The  dynamic  allocation  of  resources  within  the  NA  and  its  associated  software. 

• A simplified  implementation  of  the  application  program's  ASI  interface. 

Future  versions  of  the  ASI  may  include  the  following  features: 

• The  existence  and  concurrent  operation  of  multiple  network  adaptors. 

• The  existence  and  concurrent  operation  of  multiple  application  programs. 

• Any  combination  of  multipie/single  networks,  NAs,  and/or  application  programs. 
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The  concurrent  operation  of  the  ASI  NA  and  other  types  of  adaptors  such  as  Local  Area 
Network  (LAN)  adaptors. 
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5.  Evaluation  of  the  AS  I 


This  section  evaluates  the  Application  Software  Interface  (ASI)  as  one  element  of  an  Application 
Portability  Profile  (APP)  for  an  Open  Systems  Environment  (OSE). 

An  OSE  is  a computing  infrastructure  that  supports  portable,  scalable  and  interoperable  applications 
through  standard  services,  interfaces,  data  formats  and  protocols.  In  an  OSE,  users  will  be  able  to 
buy  and  use  applications  that 

• execute  on  any  vendor’s  platform  and  use  any  vendor's  operating  system; 

• communicate  and  interoperate  over  any  vendor’s  networks; 

• access  any  vendor's  database;  and 

• Interact  with  users  through  a common  human/computer  Interface. 

The  ASI  fits  within  this  architecture  of  the  OSE  Reference  Model  (OSE/RM)  and  provides  services 
that  fit  within  the  scope  of  the  APP  Network  Services  Functional  Area.  The  relationship  can  be  seen 
by  comparing  Figure  2 and  Figure  4 of  this  report. 

In  Figure  2,  the  APP  network  services  defined  at  both  the  API  and  the  EEI  provide  the  capabilities 
and  mechanisms  to  support  distributed  applications  requiring  data  access  and  applications 
Interoperability  In  heterogeneous,  networked  environments.  There  are  four  network  services  defined 
in  the  APP. 

• Data  communication  includes  API  and  protocol  spedfications  for  reliable,  transparent,  end> 
to-end  data  transmission  across  communications  networks. 

• Transparent  file  access  to  available  files  located  anywhere  In  a heterogeneous  network. 

• Personal/micro  computer  support  for  interoperability  with  systems  based  on  other 
operating  systems,  particularly  microcomputer  operating  systems,  that  may  not  be  formally 
standardized  in  a national  or  international  standard. 

• Remote  Procedure  Call  services  Indude  spedfications  for  extending  the  local  procedure  call 
to  a distributed  environment. 

In  Figure  4,  reference  points  A,  B and  C correspond  to  the  EEI  of  the  OSE/RM  and  reference  points 
D and  E correspond  to  the  API  of  the  OSE/RM  for  the  APP  data  communications  network  services. 
The  ASI  focuses  on  the  definition  of  a common  application  Interface  for  accessing  and  administering 
ISDN  services  provided  by  hardware  commonly  referred  to  in  the  vendor  community  as  Network 
Adapters  (NAs).  It  is  intended  to  be  independent  of  the  data  protocol  type  and  it  does  not  address 
either  peer-to-peer  protocol  or  Interoperability  Issues. 

5.1  Level  of  consensus 

Specifications  that  are  proprietary  or  are  used  by  a very  limited  or  specialized  group  of  users,  such 
as  vendor  consortia  are  given  a low  evaluation;  a high  evaluation  is  given  for  a specification  that  has 
already  become  a national  or  international  standard;  average  evaluations  are  assigned  for  public 
domain  specifications  that  are  not  standard,  or  that  may  be  In  the  process  of  becoming  a standard 
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(i.e.,  standards  committee  work-in-progress),  or  that  are  widely  available  across  various  hard- 
ware/software platforms. 

ASI  Evaluation 

The  APP  has  given  the  ASI  a high  evaluation.  The  ASI  Is  a set  of  implementation  agreements 
produced  by  the  North  American  ISDN  Users'  Forum  (NIUF).  These  agreements  are,  in  general, 
based  upon  relevant  national  and  international  standards.  While  there  has  been  interest  within  the 
NIUF  In  submitting  the  ASI  specification  to  the  standards  bodies,  the  resources  required  for  these 
activities  have  not  been  found.  Therefore,  incorporation  of  the  ASI  Into  ISDN  standards  Is  not 
underway  at  this  time  and  there  Is  no  known  plan  to  undertake  this  work  in  either  national  or 
international  standards  groups. 

5.2  Product  availability 

A low  evaluation  is  given  to  specifications  for  which  only  a very  few  proprietary  products  are 
available;  high  evaluations  are  given  to  specifications  for  which  there  is  a wide  variety  of  products 
available  from  various  vendors  across  different  application  platforms;  average  evaluations  are 
assigned  to  specifications  that  may  be  proprietary  but  have  many  products  available  from  a variety 
of  vendors,  or  that  are  public  domain  specifications  with  products  readily  available. 

ASI  Evaluation 

Current  NA  products  are  based  on  proprietary  specifications.  Several  companies  have  Indicated  that 
new  products  will  incorporate  ASI  Version  1 principles.  The  APP  has  given  the  ASI  a low  evaluation. 

5.3  Completeness 

A specification  is  evaluated  on  the  degree  to  which  it  defines  and  covers  key  features  necessary  in 
supporting  a specific  functional  area  or  service.  For  example  a network  security  specification  that 
includes  all  of  the  components  described  would  be  evaluated  higher  than  others  that  do  not  include 
all  of  the  features. 

ASI  Evaluation 

The  ASI  spedfication  provides  all  the  information  required  for  the  Implementation  of  network 
adaptors  for  many  current  computer  systems  that  use  the  DOS,  Windows  or  Unix  operating  systems. 
The  APP  has  given  the  ASI  an  average  evaluation. 

Version  1 of  the  ASI  specifies  the  call  control  service  at  the  interface  between  a computer  system 
and  the  network  adaptor.  This  is  one  element  of  the  EEI  in  the  OSE/RM.  The  API  and  other  elements 
of  the  EEI  are  not  specified  In  Version  1 of  the  ASI. 

5.4  Maturity 

According  to  the  underlying  technology  of  a specification,  a high  evaluation  indicates  that  it  is  well- 
understood  (e.g.,  a reference  model  Is  well-defined,  appropriate  concepts  of  the  technology  are  In 
widespread  use,  the  technology  may  have  been  in  use  for  many  years,  a formal  mathematical  model 
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is  defined,  etc.).  A low  evaluation  indicates  that  it  may  be  based  on  technology  that  has  not  been 
well-defined  and  may  be  relatively  new. 

ASi  Evaluation 

The  APP  has  given  the  ASI  a high  evaluation.  ISDN  technology  is  well  defined  and  understood. 
Widespread  deployment  of  ISDN  services  has  not  been  available  in  the  past  so  there  has  not  been 
a large  market  for  ASI  products.  The  ASI  will  be  considered  mature  as  soon  as  there  is  sufficient 
implementation  and  use  of  ASI  products. 

5.5  Stability 

A high  evaluation  means  that  the  specification  is  very  stable,  that  no  changes  are  expected  within 
the  next  2 years.  A low  evaluation  Indicates  that  significant  or  many  changes  are  expected  within  a 
relatively  short  time  (1  to  2 years),  or  that  Incompatibilities  exist  between  current  and  expected 
releases  of  the  specification.  An  average  evaluation  is  given  to  those  specifications  that  may  have 
known  changes  forthcoming  to  replace  features  In  the  existing  specifications. 

ASI  Evaluation 

This  specification  Is  an  evolving  interface  and  changes  may  be  required  to  incorporate  new  features. 
These  changes  are  primarily  due  to  additional  ISDN  features  as  specified  by  ANSI  and  the  NlUF.  Any 
changes  are  expected  to  be  In  the  form  of  additions  to  the  existing  specification,  not  a replacement. 
The  APP  has  given  the  ASI  an  average  evaluation. 

5.6  De  facto  usage 

This  evaluation  criterion  estimates  the  likelihood  that  a vendor  will  Independently  propose  products 
that  conform  to  this  specification,  whether  or  not  a reference  specification  is  stated  In  the 
procurement  documents.  A high  evaluation  indicates  that  most  proposed  products  will  conform  to 
the  specification.  A low  evaluation  indicates  that  it  is  unlikely  that  the  vendor  will  propose  products 
based  on  the  specifications.  An  average  evaluation  Indicates  that  vendors  are  just  as  likely  to 
propose  products  based  on  the  specifications  as  not  no  clear  determination  exists).  In  the  cases 
of  low  or  average  evaluations,  it  is  imperative  that  users  include  a specification  in  procurement 
documentation.  A low  evaluation  does  not  necessarily  mean  that  products  implemented  on  the 
specification  do  not  exist.  It  can  also  mean  that  some  vendors  would  rather  provide  products  that 
are  not  based  on  the  recommended  specifications,  such  as  proprietary  implementations. 

ASI  Evaluation 

The  APP  has  given  the  ASI  an  average  evaluation.  If  users  do  not  reference  this  specification  in 
procurement  documents,  vendors  are  not  likely  to  propose  products  that  either  meet  this 
specification  or  are  compatible  with  the  specification. 

5.7  Known  problems/limitations 

Lower  evaluations  are  assigned  to  specifications  with  severe  restrictions  on  use  or  capabilities  (e.g., 
licensing  restrictions)  or  known  problems  that  tend  to  be  too  difficult  and  too  numerous  to  overcome 
(e.g.,  new  releases  of  the  spedfication  are  not  compatible  with  previous  releases,  or  not  enough  is 
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covered  in  the  standard  to  be  useful).  An  average  evaluation  is  given  to  those  specifications  that 
require  some  minor  additional  facility  in  order  to  be  fully  effective  in  their  Intended  environment.  This 
additional  facility  may  be  provided  by  a related  standard  or  other  specification. 

ASI  Evaluation 

The  relationship  of  the  ASI  to  GOSIP  needs  to  be  clarified,  particularly  in  regard  to  the  type  of  ISDN 
service  provided.  The  ASI  specifies  both  circuit-switched  and  packet  services  while  GOSIP  specifies 
only  the  X.25  packet  service  for  ISDN.  Since  the  APP  does  not  require  GOSIP,  both  services  are 
implicitly  recommended  In  the  APP.  Thus,  the  ASI  includes  services  that  are  beyond  the  scope  of 
GOSIP.  It  Is  not  clear  whether  there  Is  a need  to  provide  a different  implementation  of  the  ASI  for 
environments  that  meet  GOSIP.  No  Implementation  of  the  ASI  tailored  for  GOSIP  is  either  known 
to  be  available  or  planned  to  be  marketed. 

The  present  version  of  the  ASI  Is  directed  toward  the  personal  computer  environment  (with  or 
without  Windows)  and  Is  limited  to  the  Unix  , DOS,  and  OS/2  operating  sytems. 


5.8  Conformance  testing 

Provides  information  about  current  and  future  plans  for  conformance  testing  of  products  based  on 
the  recommended  specification.  In  the  case  of  Federal  Information  Processing  Standards  (FIPS) 
testing,  each  FIPS  Publication  describes  the  requirements  for  testing  and  the  policies  that  affect 
such  testing.  For  other  specifications,  testing  may  or  may  not  be  described  in  the  specification 
recommended. 

ASi  Evaluation 

Conformance  tests  are  not  included  In  ASI  Version  1 and  there  are  no  known  plans  to  add 
conformance  tests  to  the  ASI  specifications.  Furthermore,  since  ASI  is  not  a standard,  conformance 
tests  are  meaningless. 

5.9  Future  plans 

Published  or  otherwise-announced  directions  and  long-term  plans  for  individual  specifications. 

ASI  Evaluation 

The  present  ASI  documents  Include  plans  for  future  work  to  include  (1)  additional  ISDN  services,  (2) 
device  control  and  (3)  additional  higher  level  Interfaces.  In  addition,  the  ASI  could  be  submitted  for 
consideration  as  an  ANSI  standard.  None  of  these  activities  are  underway  at  this  time  and  there  are 
no  known  plans  for  these  activities. 

5.10  Alternative  specification 

In  some  instances,  other  specifications  exist  besides  the  recommended  specification.  Users  may 
want  to  review  these  alternatives  before  selecting  a specification  on  which  to  standardize. 

ASi  Evaluation 
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AKhough  there  are  a number  of  specifications  which  may  be  useful  in  place  of  the  ASI,  there  Is  no 
clear  alternative  to  it  In  an  open  systems  environment.  In  general,  there  is  a lack  of  information  on 
these  specifications  and  a lack  of  analysis  on  their  utility  as  an  alternative  to  the  ASI. 
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6.  Future  Considerations 


While  the  ASI  was  developed  for  an  environment  that  utilizes  ISDN  services,  the  specification  is  also 
applicable  to  other  environments  that  utilize  other  telecommunications  services.  All  these  services, 
including  Asyncronous  Transfer  Mode  (ATM)  as  well  as  ISDN,  are  rapidly  becoming  available  In 
telecommunications  networks  throughout  the  United  States.  Since  these  telecommunications 
services  will  be  a major  element  of  the  National  Information  Infrastructure  (Nil),  the  ASI  deserves 
consideration  as  an  element  of  the  enabling  technology  required  for  the  proposed  Nil. 

The  Nil  is  a vision  for  using  presently  emerging  information  technology  to  Improve  products  and 
services,  create  new  ones,  compete  more  effectively,  and  empower  people  to  be  more  creative  and 
efficient.  The  federal  initiative  for  a Nil  envisions  a seamless  web  of  communications,  networks, 
computers,  databases  and  consumer  electronics  that  will  provide  vast  amounts  of  easily  accessible 
information  to  its  users.  The  Nil  is  expected  to  make  this  Information  available  In  the  form  of  video 
programming,  scientific  and  business  databases,  images,  sound  recordings,  library  archives  and 
other  media.  Applications  and  software  will  enable  users  to  access,  manipulate,  organize  and  digest 
the  Information. 

The  most  important  prerequisite  for  the  Nil  is  the  availability  of  computing  environments  that  consist 
of  distributed,  heterogeneous,  networked  applications,  databases,  and  hardware.  The  concept  of  a 
federal  computing  environment  that  is  built  on  an  infrastructure  defined  by  open,  consensus-based 
standards  Is  well  on  its  way  to  becoming  a de  facto  means  of  organizing  these  systems. 

The  key  Issue  Is  to  determine  how  the  ASI  fits  into  descriptions  and  specifications  of  the  Nil.  This 
is  an  architectural  issue  addressed  in  NISTIR  5478  Framework  for  National  Information  Infrastructure 
(Nil)  Services.  The  Service  Framework  presents  a "bottom  up"  view  of  the  Services  Architecture 
from  the  perspective  of  the  networks  providing  bItway-type  services.  As  such.  It  provides  a point  of 
departure  for  discussing  the  definition,  scope,  and  alignment  of  Nil  services. 

Initial  architectural  models  of  the  Nil  consisted  of  three  layers:  applications,  services  and  networks 
(also  called  b'ltways).  The  National  Research  Council  has  refined  this  model  to  the  four  layer  Open 
Data  Network  (ODN)  architecture.  This  architecture  includes  the  ODN  Bearer  Service,  an  abstract 
representation  of  the  bit-level  network  services  that  provides  a critical  separation  between  the  actual 
network  technology  and  the  higher-level  services  that  are  available  to  the  user.  The  Service 
Framework  advances  the  ODN  view  by  defining  a Nil  Services  Model  that  provides  the  next  level  of 
detail  In  the  Interfaces  between  (1)  the  bitways  and  the  services  and  (2)  the  services  and  the 
applications. 

The  Nil  architecture  may  continue  to  undergo  further  refinement  but,  at  this  point,  it  is  already  clear 
that  the  ASI  can  fit  into  the  specification  of  Nil  environments  In  three  ways: 

(1)  For  those  environments  in  the  Nil  that  incorporate  the  OSE/RM  and  the  APR,  the  ASI  is 
automatically  included. 

(2)  For  some  other  Nil  environments,  an  appropriate  profile  can  be  constructed  by  a judicious 
combination  of  present  ASI  specifications  of  the  B reference  point  for  the  EEI  with  other 
publicly  available  specifications  for  the  API. 

(3)  Future  ASI  work  on  specifications  for  the  other  reference  points  in  the  ASI  architecture  could 
satisfy  needs  for  additional  environments  within  the  Nil. 
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